home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
bgpdepl
/
bgpdepl-minutes-92mar.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
11KB
|
273 lines
This is only a rough draft - Megan 04/20/92
The BGP Deployment Working Group Meeting Summary Report
Agenda:
o BGP Deployment status and issues
o Routing policy sharing mechanism
o Next Phase NSFNET architecture discussion
1. BGP Deployment status
There are more sites/regionals using BGP in production or testing since last
IETF meeting when the group started. There are 22 regionals/sites (it was
8 last IETF) connecting to NSF/ANSNet are using BGP in production mode. Most
of them are using cisco BGP2 (BGP version 2) with their collocated NSS/ENSS.
Tow or Three sites are using gated with BGP1 or BGP2.
MILnet started beta test BGP3 on T-20 router. There are 6 or 7 Milnet sites
are using cisco to BGP3 with the T-20 router.
The BGP pilot project for the Pan-European network (Ebone) is making progress.
There are BGP peer sessions within European network. There are also a lot BGP
testing take place within European networks.
New developments in BGP implementation:
Gated supports BGP2 and BGP3 now. It is in alpha version. CA*net is using
this version to BGP2 with the NSS.
cisco has 9.0 beta which supports BGP2 and BGP3.
Tony Li at cisco did an interoperate test between the cisco and other type of
routers with BGP implementation. The result is listed in Appendix D.
Matt Methis of PSCNet gave a presentation of 'BGP Usage at PSC'. His slides
are listed in Appendix C.
2. Routing Policy Description Form
The Routing Policy sharing mechanism was discussed at the meeting. The
purpose of developing such mechanism is for each network sharing its routing
policy to keep a global routing view so each network could design and
implement their policy routing to avoid inconsistent with the global routing.
We start with develop a routing policy description form. It will be
evolved to a information base to install these kind of information and make
it available for general access. It will also define the processor to
process the information and generate inconsistency should it occur. At the
meeting, an initial draft routing policy form was discussed and agreed upon.
The Routing form is included in Appendix B. Merit will create a directory on
host nis.nsf.net to install this form for anonymous ftp. Merit will also
create a mailing list for people sending the filled forms and install them
in the directory for anonymous ftp as well.
3. The discussion of Future NSFNET backbone architecture and its routing
issues
Peter Ford led a discussion of the NSFNET recompetition architecture. His
report is included in Appendix A.
Appendix A.
NSFNET recompetition, architectural considerations.
Reported by Peter Ford, LANL. peter@lanl.gov
The National Science Foundation reported on architectural considerations
for the NSFNET recompetition which will occur during the mid-1992.
Leading the discussion were:
Robert Aiken (NSF)
Hans-Werner Braun (SDSC)
Peter Ford (LANL)
Stephen Wolff (NSF)
NSF expressed thanks to the many people who provided input into
the process of developing an architectural model for the future NSFNET
including Merit, the FEPG, the operators of the U.S. regional networks,
the FARNET membership, and the Intercontinental Engineering and
Planning Group members.
The architecture discussion focused on an interconnection
architecture for networks which either provisioned research and
education networks or those who needed to connect to the
research and education networks. NSF stated that they believed that it
is critical for the U.S. R&E networks get provisioned out of the
growing telecommunications base so that they could take advantage of
the economies of scale available in the telecommunications industry.
This should allow for maximizing the flexibility in choosing
within a parameter space defined by bandwidth, cost, reliability, etc.
The model was based on the notion of "network access points" (NAPs)
which be a chunk of shared media where networks (regionals, national,
international, multination corporate, etc.) could interconnect.
The NSF will provide support for developing a management and routing
coordination function at the NAPs. This would be done through
a collaborative agreement under the name of "routing arbiter". The
routing arbiter would provide routing support at the NAPs through the
use of a route server box which could peer with the attached networks
and send a "homogenized" picture of the routing topology dependent on
the picture a network would want to see as previously negotiated with
the routing arbiter. The NAPs would be the focal point for
evolving the internet architecture as new technologies became
available and needed to be incrementally introduced. The NAPs
would be "NSF AUP free" so commercial traffic from a U.S. regional
could go onto the NAP in the process of going to another network
which carries commercial traffic.
There would be greater than 4 and less than 17 NAPs and they would
be geographically dispersed. The NSF recompetition will
have at least 2 providers for national scale R&E traffic and they will
connect to all the NAPs. The providers are free to connect to things
other than NAPs, including regionals.
The was an extensive question and answer session, where the core
topics included:
asymmetric routes and the problems these posed
(Vince Fuller Stanford/Barrnet, Matt Mathis PSC, Milo
Medin NASA)
the issue of who could connect to a NAP (Dan Long, John Curran
BBN/Nearnet)
how the routing arbiter would be managed, with emphasis
placed on the observation that the current Merit/ANS/NSF
configuration did not have the regional networks in
a position where they were the customers of the
NSFNET backbone (Scott Bradner, Harvard/Nearnet).
Steve Wolff commented that he would like to hear
input on this topic.
AUP issues
Would regionals have to connect to a NAP? -- no.
Overall management of the 2+ providers and the NAPs?
NSF also stated that the need for maintaining the routing
database that Merit currently manages would fall under the
auspices of the routing arbiter.
The session was well attended and the discussions were vigorous. The
NSF would like to thank Jessica Yu for allowing them to barge into
the BGP deployment group meeting on short notice, and
would like to encourage any interested parties to contact the NSF
with ideas, questions, and concerns (steve@nsf.gov, raiken@nsf.gov,
peter@lanl.gov).
Appendix B.
Routing Policy Description Form (4/6/92)
-------------------------------
A. General Description of your Autonomous Systerm (AS) *
a. List the name of your AS and the AS number(s)
b. List the Routing administrator of the AS
Name:
Organization:
e-mail:
phone number:
c. List the networks that belong to your AS and mark them with RE or
non-RE type if applicable
d. List the name of your direct neighbor AS(s) and its AS number(s)
e. List each IP address of your border router(s) which interface with your
neighbor border router(s) and the Exterior Routing Protocol(s) used
respectively.
f. Is your AS a
Stub AS?
Multi-homed Stub AS?
Transit AS?
Pure Transit AS?
g. List the IGP used within your AS (optional for a non-transit AS)
h. Describe the maximum and minimum bandwidth of the transit portion of your
AS (optional for a non-transit AS).
i. Describe the delay characteristic of physical links of transit portion
of you AS, e.g., satellite, terrestrial (optional for a non-transit AS).
B. Policy Descriptions
a. For all the ASes.
o Outbound advertisement filtering:
1. list the set of nets belong to your AS that you do
not advertise to your neighbor(s).
2. list the set of nets belong to your AS that you
do not wish to be advertised to certain ASs. List
the AS numbers.
o Inbound acceptance filtering: list the set of ASs whose
nets you do or (do not) accept from your neighbor(s)
If AS number is not a satisfactory granularity, list the
set of nets.
o Describe your routing policy based on your Acceptable
Use Policy (AUP):
Does your AS accept:
1. all types of traffic?
2. only RE type traffic?
3. other? (please specify)
o Does your border router default to your neighbor border
router? If yes, described the mechanism.
b. For Multi-homed Stub ASes only:
o List the preference/denial of the neighbor ASs which can
route your traffic to the same destination (Multi-homed AS only).
c. For Transit AS only:
o List the paris of source/destination ASs or nets that your
domain does not provide transitivity.
o List the preference/denial of the ASs which can route your
traffic to a certain destination.
_____________________________________________________________________________
Note:
* The notion of Autonomous System(AS) here means the following:
a. An AS is a network blob which has a coherent Interior
routing plan and under single administration.
b. the AS number will be in the BGP AS path
Appendix C
Matt Methis' presentation slide (Megan: it was sent you via Postoffice mail
early this week, please insert it here. Thanks!)
Appendix D
BGP Interoperability Matrix
Versions tested:
a) cisco 8.2,8.3 - v2
b) cisco 9.0 (beta) - v2,v3
c) BBN T/20 2.0 - v2,v3
d) NSS/eNSS (???) - v1,v2
e) gated 2.x - v1
f) gated (alpha) - v2,v3
| a | b | c | d | e | f |
---+-------+-------+-------+-------+-------+-------+-----------------
a | same | | | | | |
---+-------+-------+-------+-------+-------+-------+-----------------
b | ok | same | | | | |
---+-------+-------+-------+-------+-------+-------+-----------------
c | ok | ok | same | | | |
---+-------+-------+-------+-------+-------+-------+-----------------
d | ok | ok | ? | same | | |
---+-------+-------+-------+-------+-------+-------+-----------------
e | vers | vers | ? | ok | same | |
---+-------+-------+-------+-------+-------+-------+-----------------
f | ok | ok | ? | ok | vers | same |
---+-------+-------+-------+-------+-------+-------+-----------------
Status:
ok - interoperability tested, found to work
same - same version, interoperability assumed
vers - lack common version
? - unknown
Tests:
Establish connection.
Negotiate version (if applicable).
Exchange routes.